【資料公開】AthenaとStep Functionsで簡単ETLオーケストレーション #midosuji_tech

Amazon AthenaとAWS Step Functionsで作る簡単なETLの仕組みのメリットと、さらに必要とされる要件に対してなにが求められるのかについて発表しました。

なにわだより

#AWS

#Amazon Athena

#AWS Step Functions

nayu.t.s

2024.06.15

データアナリティクス事業本部インテグレーション部機械学習チームの鈴木です。

2024年6月12日にクラスメソッドの大阪オフィスで開催された勉強会Midosuji Tech #1で『AthenaとStep Functionsで簡単ETLオーケストレーション』というタイトルで話しましたので資料を公開します。

当日は淀屋橋の大阪オフィスでオンサイトでイベントが開催されました。発表後にはワイワイガヤガヤタイムということで、参加者の方も交えたディスカッションが大変盛り上がりました。

発表資料

ポイント

Step FunctionsのAPI統合で、S3バケットに配置したSQLファイルをステートマシンから読み込み、Athenaで実行する仕組みを紹介しました。昔からAWSを使っている方だとLambdaをステートマシン内で呼び出し、Lambda関数でS3バケットからのファイルの読み込みやAthenaでの実行をイメージする方もいるかと思いますが、API統合を利用することで関数なしで実現できるようになっています。

また、Step FunctionsからAthenaのStartQueryExecution APIを同期呼び出しできるようにもなっていたので、こちらにも言及しました。（私が知らなかっただけかもですが...）

限られた小さな仕組みとして運用するだけなら上記の構成で十分便利なのですが、実際のところより運用しやすくしたり、今後求められるデータマネジメントの要件に対応するためには、データリネージやデータ品質管理などを実現する方法も求められます。Athenaは一度に大量のパーティションを作成することはできないので、パーティション分割した時系列のデータについて過去データを再作成したい場合にはRedshiftを採用することも視野にいれようということもご紹介しました。

討議内容と補足

当日は参加者の方と討議できる時間もあっため、そこで出た発表に関する内容と補足を記載します。当日は私以外にもAthenaの話をしたメンバーがいたため、Athenaに関する内容が多く出ました。

Redshiftの方がよい場合をもう少し聞きたい

発表内容の流れで、Redshiftの方がよい場合をご紹介しました。

ご紹介したdbtにまつわるところだと、コネクタとdbtでインストールできるパッケージの互換性です。

Redshiftはコネクタをdbt Labsがメンテナンスしていることもあってか多くの場合にパッケージがサポートしているものの、dbt-athena-communityはサポートされていない場合があり、実行してみると動かないということがありました。dbt-athena-communityが悪いわけではないのですが、パッケージもあらゆるコネクタに対応できないと思うので仕方ないと思います。

データ再作成についてだと、ロジック改修でテーブルを再作成する場合に作成済みのテーブルをrenameして新旧を入れ替えることができますが、Redshiftではテーブル名だけを変えればよいものの、Athenaの場合はGlueテーブル名を変えてもS3バケットのデータのパスは変わらないので、S3バケット上のデータのパスにも気を配らないと不整合が起こるということもあります。発表で紹介した１度に作成できるのが100パーティションまでのクォータもありますがRedshiftでは気にする必要はありません。

Athenaの速度向上について

SQLの見直しやキャパシティ予約、列統計の使用により高速化することは可能です。

また、以下のAWSブログで公開されているパフォーマンスチューニングTipsも必見です。

Amazon Athena のパフォーマンスチューニング Tips トップ 10 | Amazon Web Services ブログ

Icebergテーブルのタイムトラベルの使い所

タイムトラベルにより、スナップショットが保存されている範囲で、過去の特定時点のデータにアクセスすることができます。

Iceberg テーブルデータのクエリとタイムトラベルの実行 - Amazon Athena

過去の状態を使いたいケースは多いと思うので、活躍する場面はたくさんありますが、例えば日々UPSERTされているテーブルに対して調査を行う場合に、特定時点のデータの確認がしやすいメリットがあります。

一方でスナップショットが残ってしまうことが課題となるケースもあると考えています。例えば以下のSnowflakeの記事で紹介されているようなケースです。

GDPR：ベストプラクティス、一般的なリファレンスアーキテクチャパターン

EU一般データ保護規則（GDPR）ではユーザーは忘れられる権利を認められているため、一般的に組織は要求後30日、場合によっては90日後に個人情報をデータベースから削除する必要があります。

このようなケースに対応するためには、適切にテーブルのタイムトラベル期間を設計・設定しておく必要があります。

MSCK REPAIR TABLEとはなんですか

Hive互換のパーティションをS3バケットに追加した場合に、Glueデータカタログにメタデータを追加するためのコマンドになります。

MSCK REPAIR TABLE - Amazon Athena

Hive互換のパーティションとは、例えばs3://DOC-EXAMPLE-BUCKET/path/userId=1/のような形式のプレフィクスです。

MSCK REPAIR TABLEは非常に便利なコマンドですが、パーティション数が非常に多い場合は実行に時間がかかることに加え、あまりにも多い場合はタイムアウトすることもあります。ただし、そのような場合は基本的にはパーティションキーのカーディナリティが多いので、そのようなキーはパーティショニングに使わないか、Icebergテーブルにテーブルフォーマットを変えてハッシュによるhidden partitioningを使うのがよいと思います。（Hiveテーブルではバケッティングが使えますが、CTASのみサポートされています）